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Novell IPX Over Various WAN Media (IPXWAN) 


Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document describes how Novell IPX operates over various WAN 
media. Specifically, it describes the common "IPX WAN" protocol 
Novell uses to exchange necessary router to router information prior 
to exchanging standard IPX routing information and traffic over WAN 
datalinks. This document supercedes RFC 1362 and adds capability for 
Unnumbered RIP links, On-demand statically routed links and client to 
router connectivity. 


Table of Contents 


FPUoUOMDIATA OA ABA BRWWWWNHEPRPHRE BE 


Allen 


Oe YN 


SS UN FP 


Introduction a E A AA a 2 
Operation Over PRPP sich sth OA Se oth allows. Bie hikes MAL dd a 2 
Operation Over X.25 Switched Virtual Circuits ................ 2 
Operation Over X.25 Permanent Virtual Circuits ............... 3 
Operation Over Frame: Relay dei a a a 3 
Operation Over Other WAN Media ......oooooooooooooooooooooooo.. 3 
Glossary OF TEEMS as anr aie a aa a lun Mtn a E a von stand a E a ee oe end 4 
IPX WAN Protocol Description mt A ás 4 
The: Initial Negotiation -reses akes o E Rae S 5 
Informátion Exehange 5 685 tose ld e SRLS SE a SRLS 8 o ae ES 9 
NAK -Packets id ee ns ete deeb eee cos end ended Se See NS ke coe ed, tens Ge 10 
Information Exchange Packet Formats ............--- ee e 10 
Timer Rëgusst: Packet asa tie, Bie Sera Ge Bera te OS RE A ía a 11 
Tamer -Response Packet soraan a a Et 14 
Information. Request Packet mistral ere alles eee 15 
Information Response Packet ssi leis ee Sse eel eS ere eee ce whe Se SA ee eee 18 
Runnang~UnnuUmMbered RIP si A ada a 19 
Workstation CONnNS CE DV ACY A A a anlets ee oe oe 19 
On-demand, Statically Routed Links .....ooooooooooooooooooooo.. 19 
REESTCNCES sarya a rsa E A ile ane a a aa occa 21 
Security Considerations sse Teits bee eed igs shee dow e ie ee Fee ae es 21 
AUERNOD SAGAS SS. 2.5.2 J. ads a utile das tt le Pe ecole lore ois 22 


[Page 1] 


RFC 1551 IPXWAN December 1993 


1. Introduction 


This document describes how Novell IPX operates over various WAN 
media. It is strongly motivated by a desire for IPX to treat ALL wide 
area links in the same manner. Sections 3 and 4 describe this common 
"IPX WAN" protocol. 


The IPX WAN protocol operation begins immediately after link 
establishment. While IPX is a connectionless datagram protocol, WANs 
are often connection-oriented. Different WANs have different methods 
of link establishment. The subsections of section 1 of this document 
describe what link establishment means to IPX for different media. 
They also describe other WAN-media-dependent aspects of IPX 
operation, such as protocol identification, frame encapsulation, and 
link tear down. 


1.1 Operation Over PPP 


IPX uses PPP [1] when operating over point-to-point synchronous and 
asynchronous networks. 


With PPP, link establishment means the IPX NCP [4] reaches the Open 
state. NetWare IPX will negotiate down to a null set of NCP options, 
and uses normal frame encapsulation as defined by PPP. The IPXWAN 
protocol MUST NOT occur until the IPX NCP reaches the Open state. 
Options negotiated by the IPXWAN protocol MUST supercede any options 
negotiated by the IPXCP. 


PPP allows either side of a connection to stop forwarding IPX if one 
end sends an IPXCP or an LCP Terminate-Request. When a router detects 
this, it will immediately reflect the lost connectivity in its 
routing information database instead of naturally aging it out. 


1.2 Operation over X.25 Switched Virtual Circuits 


With X.25, link establishment means successfully opening an X.25 
virtual circuit. As specified in RFC-1356, "Multiprotocol 
Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol 
identifier 0x800000008137 is used in the X.25 Call User Data field of 
the Call Request frame, and indicates that the virtual circuit will 
be devoted to IPX. 


Furthermore, each IPX packet is encapsulated directly in X.25 data 
frame sequences without additional framing. 


Either side of the virtual circuit may close it, thereby tearing down 


the IPX link. When a router detects this, it will immediately reflect 
the lost connectivity in its routing information database instead of 
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naturally aging it out. 
1.3 Operation over X.25 Permanent Virtual Circuits 


The nature of X.25 PVC’s is that no call request is made. When the 
router is informed that X.25 Layer 2 is up, the router should assume 
that link establishment is complete. 


Each IPX packet is encapsulated in an X.25 data frame sequence 
without additional framing. Novell IPX assumes a particular X.25 
permanent circuit is devoted to the use of IPX. 


If a router receives a layer 2 error condition (e.g., X.25 Restart), 
it should reflect lost connectivity for the permanent circuits in its 
routing information database and re-perform the necessary steps to 
obtain a full IPX connection. 


1.4 Operation over Frame Relay Permanent Virtual Circuits 


To determine when a permanent virtual circuit (PVC) has become active 
or inactive, the router interacts periodically with either a private 
Frame Relay switch or a public Frame Relay network. The method used 
depends on the switch or service provider. Some support [7], section 
61 others support [3], Annex D. Novell supports both methods. 


When a router is restarted, IPXWAN exchanges over active Frame Relay 
PVCs (that is, PVCs that have remained active before and after 


restart) can begin immediately. 


Each IPX packet is encapsulated in a Frame Relay frame sequence as 
defined in [3] without additional framing. 


When a router detects that a Frame Relay PVC has transitioned from an 
inactive to an active state, link establishment is considered 


complete and IPXWAN exchange over this newly activated link begins. 


When an active PVC becomes inactive, the router reflects the lost 
connectivity in its routing information database. 


1.5 Operation over other WAN media 


Additional WAN media will be added here as specifications are 
developed. 
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2. Glossary Of Terms 
Primary Network Number: 


Every IPX WAN router has a "primary network number". This is an 
IPX network number unique to the entire internet. This number 
will be a permanently assigned network number for the router. 
Those readers familiar with NetWare 3.x servers should realize 
that this is the "Internal" network number. 


Router Name: 


Every IPX WAN router must have a "Router Name". This is a symbolic 
name given to the router. Its purpose is to allow routers to know 
who they are connected to after link establishment - particularly 
for network management purposes. A symbolic name conveys more 
information to an operator than a set of numbers. The symbolic 
name should be between 1 and 47 characters in length containing 
the characters ’A’ through ’2Z’, underscore (_), hyphen (-) and 
"at" sign (@). The string of characters should be followed by a 
null character (byte of zero) and padded to 48 characters using 
the null character. Those readers familiar with NetWare 3.x 
servers should realize that the file server name is the Router 
Name. 


For workstation (client) connectivity, it is useful if the client 
connection software is configured with a symbolic name reflecting 
the name of the client. This allows a router management utility to 
determine which connection connects with which client/router. If 
no name is configured, it is recommended that a default string 
such as "DIAL-IN-CLIENT" is used. 


3. IPX WAN Protocol Description 
After the underlying data link connection is established as described 
in the preceding media dependant description, the IPXWAN protocol is 
activated to exchange identities and determine certain operational 
charactaristics of the link. 


There are two steps in the IPXWAN operation: 


- Negotiating master/slave role and choice of routing protocol. 
The master/slave roles persist for the IPXWAN exchanges only; 


- Information exchange of final router configuration. 


After these steps are concluded, transmission of IPX routing packets 
begins - using the routing protocol negotiated - as well as 
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transmission of IPX data traffic. 
3.1 The Initial Negotiation 
The first exchange of packets decides the master/slave roles and the 


routing protocol to be used on the link and gauges the link delay for 
the routing metrics. The initial negotiation is the same for all 


protocols. 
+--------------- + +--------------- + 
| Timer Request | | Timer Request 
+--------------- + +--------------- + 
\---->\ /<----/ 
Ny 
x 
IN 
ADS a \---->\ /\ 
/ \ / \ 
/ \ / \ 
/ My primary \ / My primary \ 
/ network address\ / network address\ 
\ is larger / \ is smaller / 
\ / \ / 
\ / \ / 
\ / \ / 
\/ \/ 
MASTER SLAVE 
4+—---------------- + 
id + Timer Response + 
4+—---------------- + 


After link establishment, both sides of the link send Timer Request 

packets and start a timer waiting for a Timer Response. These Timer 

Requests are sent every 20 seconds until a response is received or a 
descision is made that the remote node is not responding. This could 
be after a predefined time (min. 60 seconds) or a number of retries 

(e.g., 16). 


In composing the Timer Request, the router or workstation takes into 
consideration: 


- Which types of routing protocols it supports; 
- Whether it is prepared to assign a network address to the link; 


- For workstations, whether they require the ability to specify 
their network/NIC address on a reconnect; 
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- Whether it is able to support IPX header compression [6]. 


For each routing protocol supported, place an option in the Timer 
Request packet. The Routing Type options should be added in the 
originator’s order of preference with the most preferred option 
first: 


Some of the newer (or modified) routing protocols do not have the 
requirement to allocate a network number on a WAN link. This type of 
routing protocol has the advantage of potentially simpler 
configuration as no network number pools are necessary for WAN links. 
However, these router implementations may still wish to interoperate 
with the older IPXWAN implementations which are able to allocate 
network numbers to the WAN link. In this case, the following method 
is used to force the older implementation to become the link master. 
It should be noted that a router implementation capable of supporting 
workstation dial-in MUST be able to supply AT LEAST ONE network 
number on which the workstation can reside. 


If the router is prepared to assign an IPX network number to the 
link, it sends its primary network number in the Timer Request 
WNodeID field, and omits the Extended Node ID option. On the other 
hand, if the router is NOT prepared to assign an IPX network number 
to the link, it sets the Timer Request WNodeID field to zero, and 
includes its primary network number in an Extended Node ID option. 


Workstations follow a similar, but slightly different set of rules 
for setting the WNodeID field. If this is the first time the work- 
station is connecting to the router, the workstation will set the 
WNodeID to zero indicating the router should be the link master and 
allocate a network number for the new link. In this case, the work- 
station will respond to the router’s Timer Request and acknowledge 
only the Workstation Routing Type option. Note that a workstation 
does NOT include an Extended Node ID option in it’s timer request. 


If the workstation is reconnecting a link after an earlier inactivity 
disconnect, it is necessary for the workstation to be able to specify 
its network, NIC address and "Router Name" field (so that file server 
connections can be maintained after the reconnect). In this case, 
the workstation will set its WNodeID field to FFFFFFFFh forcing 
itself to be the link master. In this case, the router will respond 
to the workstation’s Timer Request with only the Workstation Router 
Type acknowledged. 


Further packets in the IPXWAN exchange MUST use the correct WNodeID 
(workstations will always use zero). 
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On receiving a Timer Request packet, a router determines its role - 
master or slave - for the remainder of the IPXWAN exchanges. The 
master role does not denote special privileges, it merely means that 
the router is the requestor in the ensuing request/response 
exchanges. The descision is made as follows: 


a) If there is an Extended Node ID present (and we understand 
the option), this must be compared to our Primary Network 
Number. If we have the lower Primary Network Number, we 
MUST respond with a Timer Response and become the slave. 


b) If there is NO Extended Node ID, we must compare the WNodeID 
of the received Timer Request with our Primary Network Number 
and respond if we have a lower number. 


Note: The Primary Network Number for a workstation when 
determining master/slave roles depends on whether the 
workstation requires itself to be the master of slave. It 
should compare the received WNodeID to that sent in it’s own 
Timer Request. 


The numeric comparisons are done by considering each byte of the 
WNodeID or Extended Node ID fields as an unsigned integer, and the 
first byte as most significant. 


The link slave responds to the Timer Request with a Timer Response. 

To do so, each option in the received Timer Request is parsed. If an 
option is not supported (or recognized), that option is rejected by 

changing the WAccept field to "NO" for that option. 


When selecting the router type which will be used on the link, the 
first option in the Timer Request which can be supported should be 
accepted. All other router types should have the WAccept field set to 
"NO". A router MUST NOT accept workstation connectivity to a node 
which is another router. 


Note: It is permitted for a router to support a numbered routing 
type, but not be able to assign the network number. In this case, 
that routing type can be selected only if the other router supports 
it and is able to assign the network number. This can be determined 
by the value of the received WNodeID field. If the router is unable 
to assign a network number to the link, it MUST support Unnumbered 
RIP and include this option in the Timer Requests. 


If a router wishes to provide WAN Client access without supporting 
other WAN routing types, a potential problem arises since a router 
and WAN client would both just be sending a single Routing Type 
option indicating the use of WAN Client. The IPXWAN specification 
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does not allow a WAN workstation to connect to another WAN 
workstation. The method for detecting this is that the sent and 
received Timer Requests have a single Routing Type defined of WAN 
Client. To overcome this problem, IPXWAN defines that a router MUST 
NOT send a single Routing Type if that type is just WAN Client. The 
router MUST additionally include one (or more) of the defined routing 
types (like WAN RIP) with the WAccept option set to NO. This is so 
that a workstation may detect that this is actually a router sending 
the Timer Request and not just another workstation trying to call a 
workstation. The extra option will serve to be a counted Routing Type 
that will be ignored. If a workstation detects it is connecting to 
another workstation, it should disconnect the link. 


Note that a router supporting a workstation will need to be able to 
supply AT LEAST one network number for workstations. All dial-in 
workstations could share the same network, and be assigned unique 
node numbers by the router, or each workstation could be assigned a 
different network number. This is a router specific implementation 
detail. Use of a single network for all clients is prefered, however, 
this does involve extra work by the router when dealing with 
broadcast frames. When the router is the link master and allocating 
NIC addresses on a single network,it should ALWAYS use a unique value 
- by incrementing the NIC address for each client connection. This 
allows a workstation which is reconnecting the ability to specify his 
old network and NIC address. It is unlikely with a 6 byte NIC 
address, that there will be wrap-around in the numbers that would 
cause a problem. Router Node Number allocation should follow a few 
simple rules. The six byte NIC address SHOULD have the first byte set 
to 2. 


Byte # +--1----2----3----4----5----6-+ 
(ul A |) 0] 


In an IEEE address space, this would represent a non-multicast, 
locally defined address. Node numbers of zero or -1 are not allowed. 


If a slave determines it cannot support any of the supplied routing 
protocols in the received Timer Request, it MUST issue a disconnect 
on the connection being established. The master of the link 
(determined when a Timer Response packet is received) is responsible 
for defining the network number that is to be used as a common 
network number for the new WAN link, and for calculating the RIP 
transport time that will be advertized to other RIP routers for the 
new link. This is calculated by stopping the timer which was started 
when a Timer Request was initiated and applying the algorithm in 
section 4.3. 
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3.2 Information Exchange 


After exchanging Timer Request packets, the link master and slave 
have been determined, and the Routing Protocol to be used on the link 
is negotiated. The link master is now responsible for sending an 
Information Request packet to the slave specifying the network number 
to be used on the new link (zero for unnumbered RIP and On Demand), 
the calculated transport time to be used in the routing metric, the 
Router Name (for management purposes), and for a workstation 
connection, the NIC address the workstation will be adopting. The NIC 
address option is a separate option added in the Information 
Request/Response for workstation connectivity. It is NOT present for 
router to router connections. 


If a router receives an inappropriate Information Request from a 
workstation trying to set the common network number and NIC address 
the router MUST overwrite these values with preferred values. When 
the workstation receives the Information Response, it MUST note the 
new values. If the workstation is unable to adjust to the new values, 
it MUST issue a disconnect on the link. If a workstation is the link 
master (i.e., it is reconnecting), the router is additionally 
responsible for ensuring the "Router Name" field matches that of the 
original connection. If the values differ, the call should be 
disconnected. 


If a router detects an error for which no suitable protocol response 
exists (e.g., unable to allocate a network number), the link should 
be terminated according to the relevant media specification. 


Under certain circumstances, particularly on X.25 permanent circuits, 
it is only possible to detect the remote router went away when it 
comes back up again. In this case, one side of the link receives a 
Timer Request packet when IPX is in a fully connected state. The 
side receiving the Timer Request MUST realize that a problem 
occurred, and revert to the IPX link establishment phase. 
Furthermore, the routing information learned from this connection 
should be immediately discarded. 


When Unnumbered RIP, On-demand or Workstation options are negotiated, 
Information Request packets are repeated every 20 seconds until a 
response is received. For the Numbered RIP links, the Information 
Request is NOT resent. Instead, the link is disconnected after a 
suitable delay (min. 60 seconds) - this requirement ensures 
interoperabilty with earlier versions of IPXWAN. When Information 
Requests are repeated, they should continue for a preconfigured time 
(min. 60 seconds) or a preconfigured number of retries (e.g., 16). 
Each retry uses an incremented sequence number. 
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3.3 NAK Packets 


The IPXWAN protocol uses a NAK packet to indicate the received IPXWAN 
packet was not acceptable. A NAK packet is an exact copy of the 
received packet with the WPacketType field set to NAK. There are two 
anticipated uses of this packet. 


- The received WPacketType is invalid or not recognized; 
- A badly formed IPXWAN packet is received. 


Returning a NAK packet allows the sender a chance to work out what 
was wrong. If the sender was unable to determine the problem, the 
call can then be disconnected. 


The value of the NAK WPacketType is FFh. 
4. Information Exchange Packet Formats 


All IPX WAN protocol exchanges utilize the standard Novell IPX packet 
format. The packets use the IPX defined packet type 04 defining a 
Packet Exchange Packet. The socket number 0x9004 is a Novell reserved 
socket number for exclusive use with IPX WAN protocol exchange. IPX 
defines that a network number of zero (0) is interpreted as being a 
local network of unknown number that requires no routing. This 
feature is of use to us in transferring these packets before the 
common network number is exchanged. Some routers need to know a "Node 
Number" (or MAC address) for each node on a link. Node numbers will 
be formed from the "WNode ID" field. The node number will be the 4 
bytes of WNode ID followed by 2 bytes of zero. For a workstation, the 
node number will be explicitly assigned by the router and notified to 
the workstation in the Information Request packet. 


Router Type number assignment. Other vendors IPX routing protocols 
can make use of the IPXWAN protocol definition by obtaining Router 
Types from Novell. This document will then include the new Router 
Types (with the references to vendor protocol description documents). 
Current Routing Types are: 


00 Numbered RIP/SAP 

01 NLSP (no RIP/SAP - defined in [8]) 

02 Unnumbered RIP/SAP 

03 On Demand, static routing (no RIP/SAP or NLSP) 
04 Workstation (no RIP/SAP) 


05-FF Currently undefined 


WOption Number assignment. These numbers only need to be assigned 
from Novell for the "Timer Request" and "Timer Response" packets. 
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Packet Types also need to be assigned by Novell. However, the options 
within these packets are dependant on the "Router Type" negotiated. 
WOption numbers in these packets are then defined by the vendor 
defining the Routing Type. The same packet format should still be 
maintained. 


Router Type 01 will not be described in this document since it 
involves knowledge of the NLSP protocol to implement. Please refer to 
[8] for a complete specification of these NLSP IPXWAN exchanges and 
the NLSP protocol. 


4.1 Timer Request Packet 


Checksum Always FFFF | 


| | | 
Packet Length 02 40 Max IPX size (576 bytes 
| | | Hi Lo order) 
| Trans Control | 00 | Hops traversed 
| Packet Type | 04 | Packet Exchange Packet | 
| Dest Net # | 00 00 00 00 | Local Network | 
| Dest Node # | FF FF FF FF FF FF | Broadcast | 
| Dest Socket # | 90 04 | Reserved WAN socket | 
Source Net # 00 00 00 00 Local Network 
| Source Node # | 00 00 00 00 00 00 | Set to zero | 
| Source Socket # | 90 04 | Reserved WAN socket 
|------------------ Ho $------------------------ | 
| WIdentifier | 57 41 53 4D | Confidence identifier | 
WPacket Type 00 Timer Request 
| WNode ID | XX XX XX XX | Primary Net + of 
| | | sending router | 
| | | (Hi Lo order) | 
| WSequence # | XX | Sequence start at 0 | 
| WNum Options | xx | Number of options 
=== a 4+ 
| WOption Number | XX | Option Identifier 
| WAccept Option | xx | O=No,1=Yes,3=Not Applic| 
| WOption Data Len | XX XX | Number of following 
| | | option bytes (Hi Lo) | 
| WOption Data | nn | Option specific data | 
A O + 


Routing Type Option: 
One or more of the following router type options should be included 
in a Timer Request packet. A router should ALWAYS include Routing 
Type zero (0) if full interoperability is required with an older 
implementation. The router types MUST be included in the senders 
order of preference. If a router receives a Timer Response with more 
than one Router Type having WAccept set to Yes, the link MUST be 
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disconnected. 
Pie eo Sa eee ee ee eS ee Se ee eo ee e + 
| WOption Number | 00 | Define Routing Type | 
| WAccept Option | O1 | O=No,1=Yes,3=Not Applic| 
| WOption Data Len | 00 01 | Option length (Hi Lo) | 
| WOption Data | 00 | IPX RIP/SAP Routing 
BA 5-5-5 5 5 5 5 = + 
A A eS Se ee ee a e a + 
| WOption Number | 00 | Define Routing Type | 
| WAccept Option | 01 | O=No,1=Yes,3=Not Applic| 
| WOption Data Len | 00 01 | Option length (Hi Lo) | 
| WOption Data | 01 | NLSP 
he Se Se ee ee ee ee eS ee ee eee + 
PSS SSS aS So Se Se eS Se Se So ee sae + 
WOption Number 00 | Define Routing Type 
WAccept Option 01 O=No, 1=Yes, 3=Not Applic 
| WOption Data Len | 00 01 | Option length (Hi Lo) | 
| WOption Data | 02 | Unnumbered RIP/SAP | 
O + 
A A A O o ee + 
WOption Number 00 | Define Routing Type 
WAccept Option | 01 O=No, 1=Yes, 3=Not Applic 
| WOption Data Len | 00 01 | Option length (Hi Lo) | 
| WOption Data | 03 | On-demand, static Rting| 
tarta pra ee BS ee ee Sea eee + 
PSS SSeS Se SS S Sea Se SS SSS Se SS aS + 
WOption Number 00 | Define Routing Type 
WAccept Option | 01 0=NO, 1=Yes, 3=Not Applic 
| WOption Data Len | 00 01 | Option length (Hi Lo) | 
| WOption Data | 04 | Client - No RIP/SAP | 
| | | except on request | 
a E + 


Extended Node ID Option: 
The extended node ID should only be included if the WNodeID field is 
set to zero AND the node constructing the packet is a router. Note 
that an older version of IPXWAN will just reject this option and 
automatically become the link master as the WNodeID is zero. 


| WOption Number | | Extended Node ID | 
| WAccept Option | | 0=No, 1=Yes, 3=Not Applic| 
| WOption Data Len | 00 04 | Pad data length (Hi Lo) | 
| WOption Data | | Real primary network # | 
| | | of this router (Hi-Lo) | 
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Header Compression Option: 
Although more than one header compression option may be specified in 
a Timer Request packet, it is important that a MAXIMUM of ONE header 
compression option is accepted. If an implementation receives a 
Timer Response with more than one header compression option with the 
accept option set to Yes, the link MUST be disconnected. [Ref 6] 
defines the full Telebit Header Compression method. 


| WOption Number | | Header Compression | 
| WAccept Option | | 0=No, 1=Yes, 3=Not Applic| 
| WOption Data Len | 00 03 | Variable - at least 1 | 
| WOption Data | | 
| | | 
| | | 


00 0 = Telebit Hdr Compr. | 
XX Compression Options | 
XX Compression Slots | 
HASTA AR SA ESA a SS Ss a See Sees ss + 


PAD Option: 
The PAD option is used to fill the Timer Request up to the 576 byte 
limit. This field will be of variable length depending on the number 
of other options in the packet. This option will normally be the 
last entry in the packet. Its sole purpose is to fill the IPX 
packet to be 576 bytes. The pad option data should be filled with a 
selection of totally random numbers to avoid compression modems or 
PPP data compression from destroying the link delay calculation. 
Note that this is different from the original RFC 1362 
specification. This should not affect implementations. 
Implementations should not attempt to verify the contents of a PAD 


option. 

SS ee ee ee ee ee + 

| WOption Number | FF | Pad option 

| WAccept Option | 01 | O=No,1=Yes,3=Not Applic| 
WOption Data Len XX XX Pad data length (Hi Lo) 

(enough to fill packet) 

| WOption Data | Random numbers | 

A E + 

Note 


Timer Request packets will always be 576 bytes. However, 
there should be no assumption made about the number of 
options specified in this packet. 


After link establishment, Timer Request packets are sent by both 
sides of the link. Each end starts their sequence number at zero. 
Subsequent retries (every 20 seconds) will increment the value of 
this sequence number. Only a Timer Response packet with a sequence 
number matching the last sent sequence number will be acted upon. 
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As mentioned earlier, the WNodeID field may be set to zero fora 
router if it is unable to provide a network number for the link. If 
a router ONLY supports the Numbered RIP/SAP option, it MUST be 
capable of proving a network number for a WAN link. 


Packets received on the reserved socket number not having the 
WIdentifier set to the hexadecimal values noted above should be 
discarded. 


4.2 Timer Response Packet 


Always FFFF | 
Max IPX size (576 bytes| 
Hi Lo order) 


Checksum | | 
| | 
| | 
Trans Control | 00 | Hops traversed 
| | 
| | 
| | 
| | 


Packet Length 


Packet Type 04 Packet Exchange Packet 
Dest Net # 00 00 00 00 Local Network 

Dest Node + FF FF FF FF FF FF Broadcast 

Dest Socket + 90 04 Reserved WAN socket 
Source Net + 00 00 00 00 Local Network 

Source Node + 00 00 00 00 00 00 Set to zero 

Source Socket + 90 04 Reserved WAN socket 


A A a 
WIdentifier | 57 41 53 4D | Confidence identifier 
WPacket Type | 01 | Timer Response 
WNode ID | XX XX XX XX | Primary Net # of 

| | sending router 
(Hi Lo order) 
WSequence # | xx | Same as Timer Request 
| | received 
WNum Options | xx | Number of options 

EE a E et a 
WOption Number XX Option Identifier 
WAccept Option XX O=No, 1=Yes, 3=Not Applic 
WOption Data Len | XX XX | Number of following 

| | option bytes (Hi Lo) | 
WOption Data | nn | Option specific data | 
22223522920 SS SS Se Se SS Sr SS Se + 


The options contained within this packet are as described in section 
4.1 Any unknown options or not supported options within the Timer 
Request MUST have the WAccept Option set to NO in the Timer Response. 


If the Timer Request packet contained more than one Router Type 
option and the "Slave" supports all the options, the "Slave" MUST set 
the WAccept Option to YES on the FIRST Router Type supported and NO 
to ALL other Router Types. This is the Router Type which is to be 
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Information exchanges will then 


This packet must contain the same sequence number as the received 


Timer Request. 


This packet should ONLY be sent by the router or 


workstation determining themselves to be the "Slave" of the link. 
(Workstations are ALWAYS the link slave). 


Routers MUST set the WNodeID to their correct value when responding 
with the Timer Response. A value of zero must NOT be used. 


4.3 Information Request Packet 


Checksum | FF 
Packet Length | 00 
Trans Control | 00 
Packet Type | 04 
Dest Net # | 00 
Dest Node # | FF 
Dest Socket # | 90 
Source Net # 00 
Source Node # | 00 
Source Socket # | 90 
A ee SS ee ee + 
WIdentifier | 57 
WPacket Type 02 
WNode ID | XX 
| 
| 
WSequence # | 00 
WNum Options | 01 
WOption Number | 01 
WAccept Option | 01 
WOption Data Len | 00 
WOption Data | 
Link Delay | XX 
Common Net # | xx 
Router Name | xX 


XX 


36 


XX 


00 
FF 


XX 


XX XX XX 
(x 48 decimal) 


FF FF 


Always FFFF | 
Size of header+data | 
(Hi Lo order) 
Hops traversed | 
Packet Exchange Packet | 
Local Network 
Broadcast | 
Reserved WAN socket 
Local Network 
Set to zero | 
Reserved WAN socket | 
Confidence identifier | 
Information Request 
Primary Net # of | 
sending router | 
(Hi Lo order) | 
Sequence start at 0 | 
1 Option to follow | 
Define IPX RIP/SAP | 
info exchange 
0=No, 1=Yes, 3=Not Applic| 
Option length (Hi Lo) | 
| 
| 
| 
| 


Hi Lo link delay in 
milli seconds (see 
below for calculation) 
Hi Lo Common Network # 
Router name - as defned 
in section 2. 


Routers MUST set the WNodeID to their correct value when sending an 
Information Request. A value of zero must NOT be used. 
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A workstation should replace the Router Name with the configured 
name, or a constant descriptor string as described in section 2. 


For a Workstation Information Request, an extra option is added which 
specifies the NIC address for the workstation. In this case, the 
number of options will be set to two (2). 


HO - - - - 5 = + 
WOption Number 05 Define NIC Address 
WAccept Option 01 O=No, 1=Yes, 3=Not Applic 

| WOption Data Len | 00 06 | Option length (Hi Lo) | 

| WOption Data | 02 xx xx xx xx xx | NIC Address for W/S | 

4+----------------- O O = + 


Routers or workstations should not refuse to use a NIC address having 
a first byte with a value other than 02. 


Calculation of link delay is performed as follows: 


// Start_time is a time stamp when Timer Request sent out 
// End_time is a time stamp when a Timer Response is 
// received. 
link_delay = end_time - start_time; // 1/18th second 
if (link delay < 1) 
{ 

link_delay = 1; 
}/*IF*/ 
// We are on a slow net, so add some biasing to help stop 
// multiple workstation sessions timing out on the link 
link_delay *= 6; /* Add the biasing for multiple sessions */ 
link_delay *= 55; /* Convert link delay to milliseconds */ 


If a higher resolution timer is available, better results may be 
obtained using the following algorithm: 


conversion_factor = number of timer units in 1/18th second; 
link_delay = ((end_time - start_time) * 6) / conversion_factor; 
if (link_delay == 0) 
{ 

link_delay = 1; 
} /*IE*/ 
link_delay *= 55; /* Convert link delay to milliseconds */ 


The "Link Delay" is used as the network transport time when 
advertized in the IPX RIP packet tuple for the network entry "Common 
Net #". For a consistent network, a common link delay is required at 
both ends of the link and is calculated by the link "Master". Link 
Delay is specified in milli seconds. 
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The Common Net # is supplied by the link "Master". This number must 
be unique in the connected internetwork. Each WAN call requires a 
separate number. If the negotiated Router Type was Unnumbered RIP, 
On-demand, or NLSP, the specified Common Net # will be zero. 


This packet should contain a sequence number starting at zero. This 
packet should ONLY be sent by the router or workstation determining 
themselves to be the "Slave" of the link. 


If extra options are included in this packet, they should be silently 


discarded.If the information option is missing, the link MUST be 
disconnected. 
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4.4 Information Response Packet 


Checksum Always FFFF 


Packet Length 00 63 Size of header+data 
(Hi Lo Order) 

Trans Control 00 Hops traversed 

Packet Type 04 Packet Exchange Packet 

Dest Net + 00 00 00 00 Local Network 


Source Net + Local Network 
Source Node + 


Source Socket + 


Set to zero 
Reserved WAN socket 


| | 
| | 
| | 
| | 
| | 
Dest Node # | FF FF FF FF FF FF | Broadcast 
Dest Socket # | 90 04 | Reserved WAN socket 
| | 
| | 
+ + 


WIdentifier 57 41 53 4D Confidence identifier 
WPacket Type 03 Information Response 
WNode ID XX XX XX XX Primary Net + of 


(Hi Lo order) 


WSequence + 00 Same as Info Request 
WNum Options 01 1 Option to follow 
WOption Number 01 Define IPX RIP/SAP 

info exchange 
WAccept Option 01 O=No, 1=Yes, 3=Not Applic 
WOption Data 
Link Delay XX XX Hi Lo link delay (as 


received in Info Requ) 
Hi Lo Common Network # 
(as received in Info 
request) 

Router name - as defned 
in section 2. 


Common Net + XX XX XX XX 


Router Name xx (x 48 decimal) 


| 
| 
| 
| 
| 
| 
| 
| 
| 
sending router | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| | 
| | 
| | 
| | 
WOption Data Len | 00 36 | Option length (Hi Lo) 
| | 
| | 
| | 
| | 
| | 
| | 


The responses contained within this packet are as described in 
section 4.3. 


A link slave will additionally respond with the received NIC address 
option as a confirmation of receipt. A workstation should replace the 
Router Name with the configured name, or a constant descriptor string 
as described in section 2. If the Information Request contained an 
inappropriate Common Net # or NIC address, the Information Response 
may set new values. The receiver of the Information Response is 
responsible for checking on the value and terminating the connection 
if the new values cannot be used. 
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Routers MUST set the WNodeID to their correct value when sending an 
Information Response. A value of zero must NOT be used. 


5. Running Unnumbered RIP 


Unnumbered RIP refers to the case where two WAN routers are 
communicating using the RIP protocol across a link with NO physical 
IPX network address. The premise for this ability is that there is no 
need to address a packet to anything on that WAN link. RIP and SAP 
run in exactly the same way as before, except the source and 
destination network numbers should be set to zero. 


The advantage to running unnumbered RIP links is that it is not 
necessary to allocate/configure a pool of usable IPX network numbers 
which can be used on the WAN links. The other advantage is that when 
there is a large number of WAN links, it is not necessary to flood 
the network with an unnecessary set of extra RIP information. 


6. Workstation Connectivity 


Workstations MUST reside on a network and have a unique NIC address 
on that network to be individually addressable. However, workstations 
do not need to periodically receive RIP and SAP broadcasts as they 
play no part in the routing process. This allows routers to reduce 
background traffic on the workstation link by not sending any 
periodic RIP and SAP data. Note that it will not cause a problem if 
the RIP and SAP is sent. It will just slow down the workstation 
access times. 


RIP and SAP information should ONLY be sent if the workstation makes 
a specific request for information - like a service or route request. 


It should also be noted that if multiple workstations are attached to 
a single WAN workstation network (per router), broadcasts on that 
network - whether originated from a workstation or the router - MUST 
reach ALL other workstations. This will involve the router 
duplicating the packet to all WAN workstation connections. 


7. On-demand, Statically Routed Links 


On-demand, Static Routing serves two purposes. The "on-demand" part 
means that a router initiates communication to a destination only 
when there is data to be forwarded to that destination. "Inititating 
comunication" includes making a datalink call (where necessary) and 
performing the IPXWAN exchange. A transient connection is closed 
after a period of inactivity. 
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The "static routing" part means that no routing information is sent 
over the link - no RIP, no SAP, and no NLSP. Instead, the router at 
each end is configured with the routes and services accessible 
through the link. 


With on-demand, static routing, the called router must be able to 
identify the calling router so that statically configured routes and 
services can be attached to that connection. For example, with X.25 
switched virtual circuits, the calling DTE address can be used; with 
PPP, the PPP authentication can be used; after IPXWAN has completed, 
the "Router Name" can be used; with a persistent datalink connection, 
the physical port identifier or a permanent virtual circuit 
identifier can be used. The choice of identifier is an implementation 
decision. Whatever value the called router uses is called a Remote 
System Identifier, or RSI. For PPP links, Novell uses PPP PAP or CHAP 
authentication to determine the caller. 


A router implementing on-demand, static routing must maintain a 
database of RSIs, and lists describing the network numbers and 
services reachable through each RSI. These lists determine the 
reachability information it transmits to other routers in a routing 
area. Other routers treat each on-demand, static routing link as 
though it were permanently available. 


The on-demand exchange has a slight variation on the IPXWAN protocol. 
The differences are as follows. 


In the Timer Request, the calling router offers only the "On-demand, 
static routing" Routing Type. If the called router is capable of On- 
demand static routing, it offers "On-demand, static routing" in the 
Timer Request, along with any additional routing types it is willing 
to support on the link. The Master/Slave election and choice of 
routing type proceeds as described previously. If the Slave detects a 
mismatch in routing types, it disconnects the link. 


For a persistent datalink (like X.25 PVCs), there may be no 
descerable "link establishemnt" event. For such media, arrival of a 
Timer Request plays the role of detecting link establishment. 


As with Unnumbered RIP, there is no network number assigned to the 
link. NLSP Packets are not sent on the link. Moreover, periodic RIP 
and SAP packets are not sent on the link. However, a router must 
respond to RIP and SAP queries received on the link. 
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9. Security Considerations 


Security issues are not discussed in this memo. 
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